Engineers don't want to read this. Framer has, until recently, been a tool a serious engineering team would dismiss in five seconds. The implication was that real products get built in real code, and Framer is for designers who can't ship. That implication is now wrong. We have been using Framer in production for three years across multiple clients, and our default for marketing-class sites is no longer "Next.js from scratch." It is "Framer first, and switch to Next.js when we find the wall."

This is the field note on where the wall is, why most engineering teams overestimate how soon it shows up, and the workflow that lets us ship marketing platforms in weeks that custom-built peers ship in quarters.

Where Framer holds up

For a defined class of work — marketing sites, brand pages, campaign microsites, founder portfolios, blog-style content — Framer is now production-grade. Specifically:

Performance. Framer ships static HTML, CDN-delivered, with image optimisation and lazy loading baked in. Lighthouse scores on our last five Framer projects: all above 95 on mobile, all 100 on desktop. Better than several custom Next.js builds we have inherited.

SEO. Per-page meta tags, OG, structured data, sitemap, robots, canonical — all in. The defaults are good. The advanced controls are there when you need them.

Responsiveness. The breakpoint system is now solid. Layouts behave on every device we test. Edge cases (foldables, ultra-wide) need attention but are manageable.

Animation and motion. Where Framer started, and where it remains best in class. Smart Components, scroll-linked animations, page transitions — better than what a custom team would build in the same time, by a wide margin.

Speed of iteration. The killer feature. A designer can ship a layout change in minutes that would take a custom team a day. Marketing teams that depended on engineering tickets for every copy edit get their lives back.

Where Framer breaks

The wall exists. We hit it on every project that grew beyond marketing.

Auth and accounts. Framer can do basic gated content. It cannot do session management, role-based access, multi-tenant flows. The moment "login" matters, the wall is in sight.

Real data, real backends. Framer can fetch from an API and render. It cannot host the API, run a database, or process forms with side effects beyond a simple submit-to-email. If users are reading from or writing to your data, Framer is the wrong tool.

Complex state and interactivity. Anything that resembles an app — multi-step flows with branching state, real-time updates, drag-and-drop builders, calculators with non-trivial logic — quickly outgrows Framer's interaction primitives. You can fight it. You shouldn't.

Custom infrastructure needs. Compliance environments, on-prem hosting, custom CDN behaviour, server-side rendering tied to user identity — all out. Framer's hosting is excellent for what it does and a non-starter for these cases.

Long-term ownership. Framer is a vendor. If they raise prices, change pricing tiers, or get acquired, you have a migration problem. We have not had to migrate, but we plan as if we might.

The workflow that makes this fast

The compounding advantage of using Framer for the right work is not the tool itself. It is the workflow that the tool enables.

Designers ship. When the design tool is the deployment tool, the cycle from "the founder wants a new headline" to "the new headline is live" collapses from days to minutes. The designer makes the change, hits publish, the URL updates. No PR, no review queue, no Friday-night deploy. Marketing teams that experience this for the first time describe it as a different job.

Engineering keeps the high-value work. The engineering team is not building landing pages. They are building the things only engineers can build: the product, the API, the infrastructure, the AI features. Their time is not eaten by "the homepage hero needs to be 8px taller." The studio gets a higher-quality product because the engineering attention is on the part of the work where engineering attention matters.

The brand stays coherent. Because the marketing surface and the product surface are designed with the same tokens (more on this below), the brand reads as one thing even though it is shipped through two stacks.

Design tokens across both stacks

The pattern that makes the dual-stack workflow actually work: a shared token system that both Framer and the codebase consume.

We define colours, type scale, spacing, motion timings, and breakpoints once. The codebase imports them as TypeScript constants. Framer reads them as a Style Library imported from the same source of truth. Change a token, both surfaces update.

This is the part most teams skip and pay for later. Without it, the marketing site and the product drift visually. The button on the marketing page has 16px padding, the button in the app has 14px. The brand stops being one brand. The fix is not stronger Slack messages between teams. The fix is shared tokens.

The marketing site and the product drift visually because the button on the marketing page has 16px padding and the button in the app has 14px. The fix is shared tokens.

When to switch to Next.js

The decision is rarely "Framer or custom" — it is "what fraction of this product is Framer-shaped and what fraction is not." Our rule of thumb:

Framer for: the marketing site, the brand pages, blog and editorial content, campaign microsites, the careers page, the press room. Anything where the page-edit velocity matters more than the runtime customisation.

Next.js for: the product itself, the customer dashboard, the admin tools, the internal apps. Anything where you need session state, server logic, or compliance control.

The split lives at the subdomain or path level. marketing.client.com is Framer. app.client.com is Next.js. Both share the tokens. Both deploy independently. Both feel like one company.

What the engineering team thinks of all this

Engineers we work with were sceptical for the first month and converts by the third. Two reasons.

One — they get their time back. The number of "the homepage needs..." tickets that hit their backlog dropped to zero. They are doing the work that pays for their salaries.

Two — the marketing team's experiments ship faster, which means the engineering team gets clearer signal on what to build into the product. The pace of learning improves. The product gets better-targeted because the marketing iteration loop is faster than it ever was inside the engineering queue.

Closing

Framer is no longer a tool serious teams should dismiss. For the work it is good at, it is now better than the custom alternative. The studios still building marketing sites from scratch in Next.js are doing the equivalent of writing their CMS in PHP in 2008 — possible, sometimes principled, almost never the right call.

Pick the right tool for the layer. Share the tokens across layers. Ship.